Openfire 4.6.0 contains a stored cross-site scripting vulnerability in the nodejs plugin that allows attackers to inject malicious scripts through the 'path' parameter. Attackers can craft a payload with script tags to execute arbitrary JavaScript in the context of administrative users viewing the nodejs configuration page.

Summary

Identity spoofing in X.509 client certificate authentication in Openfire allows internal attackers to impersonate other users via crafted certificate subject attributes, due to regex-based extraction of CN from an unescaped, provider-dependent DN string.

Analysis

Openfire’s SASL EXTERNAL mechanism for client TLS authentication contains a vulnerability in how it extracts user identities from X.509 certificates. Instead of parsing the structured ASN.1 data, the code calls X509Certificate.getSubjectDN().getName() and applies a regex to look for CN=. This method produces a provider-dependent string that does not escape special characters. In SunJSSE (sun.security.x509.X500Name), for example, commas and equals signs inside attribute values are not escaped.

As a result, a malicious certificate can embed CN= inside another attribute value (e.g. OU="CN=admin,"). The regex will incorrectly interpret this as a legitimate Common Name and extract admin. If SASL EXTERNAL is enabled and configured to map CNs to user accounts, this allows the attacker to impersonate another user.

Impact

When there is no explicit configuration override, Openfire defaults to using certificate attributes as follows:

- Server-to-server certificates: first the Subject Alternative Name (SAN), and if that is not available, the Common Name (CN). - Client-to-server certificates: only the Common Name (CN).

Use of CN for identity mapping was phased out by the CA/Browser Forum. CAB Forum-compliant CAs no longer allow arbitrary Subject RDNs and always include SANs. As a result, certificates issued by public CAs for use on the open Internet are unlikely to be exploitable, though older certificates still within their validity period could theoretically be abused.

The primary risks exist in private CA environments and client certificate authentication, where identity mapping may rely solely on the CN. Both of these are niche deployment scenarios.

Patches

The path has been prepared by replacing the use of getSubjectDN().getName() with standards-compliant LdapName parsing of the RFC2253 representation of X500Principal. This avoids unescaped provider-dependent strings and prevents regex from matching malicious substrings.

The fix is included in Openfire 5.0.2 and 5.1.0. Users should upgrade to this version as soon as it becomes available.

Starting in Openfire 5.0.2, Openfire will by default prefer a Subject Alternative Name-based identity over a Common Name based one for client-to-server authentication (issue OF-3123). For server-to-server authentication, this already is the case.

In Openfire 5.1.0, Openfire will no longer, by default, use Common Name based identities, although this functionality can be restored through configuration changes (issue OF-3122). Workarounds

The vulnerability is fixed in the upcoming release, but there are operational mitigations you can apply today.

Full workaround (drop-in replacement JAR using the fixed mapper) This is a complete workaround: 1. Take the fixed mapper implementation (the code that uses LdapName / RFC2253 parsing) from the patched Openfire source. 2. Create a new Java class in your proprietary namespace (for example com.acme.openfire.SafeCNCertificateIdentityMapping) that implements the same Openfire certificate-identity mapping interface and contains the fixed parsing logic. Ensure the logic exactly mirrors the patched behavior (use X500Principal.getName() with RFC2253 and javax.naming.ldap.LdapName to parse RDNs, do not rely on getSubjectDN().getName() or provider-dependent strings). 3. Package the class into a JAR file. 4. Place the JAR into Openfire’s lib/ directory (e.g. $OPENFIREHOME/lib/your-fixed-mapper.jar). 5. Configure Openfire to use your class for mapping by setting the following properties (in the admin console / system properties). Note that it remains advisable to configure Openfire to keep preferring SAN-based identities: For server-to-server identity mapping provider.serverCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping

For client-to-server identity mapping provider.clientCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping Both properties accept a comma-separated list of fully-qualified class names; listing only your safe mapper forces Openfire to use your implementation instead of the vulnerable built-in mapper. After placing the JAR and updating properties, restart Openfire.

Notes & caveats for the full workaround

- This is effectively a complete mitigation for the vulnerable CN-extraction behavior without deploying a new official release. - Maintain the JAR: you are responsible for keeping the custom class updated if you upgrade Openfire to newer major versions. - Ensure your custom mapper truly implements the patched parsing (do not copy the vulnerable getSubjectDN().getName() + regex approach). Use X500Principal → getName(RFC2253) → new LdapName(...) → iterate RDNs in a robust way. - Because this runs in the Openfire JVM, follow your organization’s binary-signing and review policies before deploying.

Other, lesser workarounds

Use SAN-only mapping Configure the mapper list to only include Openfire’s SAN mapper: org.jivesoftware.util.cert.SANCertificateIdentityMapping. This prevents CN parsing-based spoofing but breaks authentication for certificates that contain only a CN and no SAN.

Disable certificate-based authentication: - For server-to-server, disabling certificate auth leaves only Server Dialback, which is less secure; depending on your environment, this may be a worse trade-off. - For client-to-server, disable “mutual authentication” in the admin console to stop client cert authentication altogether.

References

- Openfire issue tracker: OF-3124: Potential identity spoofing via unsafe CN parsing - Affected code: CNCertificateIdentityMapping.java#L43 - Openfire issue tracker: OF-3122: Stop by default using Common Name based identities - Openfire issue tracker: OF-3123: For client mutual authentication, prefer Subject Alternative Name for identities

An important security issue affects a range of versions of Openfire, the cross-platform real-time collaboration server based on the XMPP protocol that is created by the Ignite Realtime community.

Impact Openfire's administrative console (the Admin Console), a web-based application, was found to be vulnerable to a path traversal attack via the setup environment. This permitted an unauthenticated user to use the unauthenticated Openfire Setup Environment in an already configured Openfire environment to access restricted pages in the Openfire Admin Console reserved for administrative users.

Cause Path traversal protections were already in place to protect against exactly this kind of attack, but didn’t defend against certain non-standard URL encoding for UTF-16 characters, that were not supported by the embedded webserver that was in use at the time.

A later upgrade of the embedded webserver included support for non-standard URL encoding of UTF-16 characters. The path traversal protections in place in Openfire were not updated to include protection against this new encoding.

Openfire's API defines a mechanism for certain URLs to be excluded from web authentication (this, for example, is used for the login page). This mechanism allows for wildcards to be used, to allow for flexible URL pattern matching.

The combination of the wildcard pattern matching and path traversal vulnerability allows a malicious user to bypass authentication requirements for Admin Console pages.

Affected versions This vulnerability affects all versions of Openfire that have been released since April 2015, starting with version 3.10.0. The problem has been patched in Openfire release 4.7.5 and 4.6.8, and further improvements will be included in the yet-to-be released first version on the 4.8 branch (which is expected to be version 4.8.0).

Problem Reproduction To test if an instance of Openfire is affected, follow these steps. Open a browser in incognito mode, or otherwise ensure that there is no authenticated session with the Openfire admin console. Open the following URL (possibly modified for the hostname of the server that is running Openfire):

http://localhost:9090/setup/setup-s/%u002e%u002e/%u002e%u002e/log.jsp

If this shows part of the openfire logfiles, then the instance of Openfire is affected by this vulnerability. Note that different versions of Openfire will show a different layout. Newer versions of Openfire can be expected to show log files on a dark background, while older versions will show a largely white page. (Depending on the content of the log file, this page might be empty, apart from a header!)

If there's a redirect to the login page, the instance is likely unaffected.

Problem Resolution The problem has been patched in Openfire release 4.7.5 and 4.6.8, and further improvements will be included in the yet-to-be released first version on the 4.8 branch (which is expected to be version 4.8.0).

- In Openfire 4.6.8, 4.7.5 and 4.8.0, Path Traversal pattern detection has been improved to include detection of non-standard URL encodings, preventing any non UTF-8 characters. - In Openfire 4.6.8, 4.7.5 and 4.8.0, a new configuration property (adminConsole.access.allow-wildcards-in-excludes) is introduced that controls the permissibility of using wildcards in URL-patterns that define exclusions to authentication. - In Openfire 4.6.8, 4.7.5 and 4.8.0, the existing value that uses a wildcard in URL-patterns that define exclusions to authentication has been replaced by values that do not depend on a wildcard. - In Openfire 4.6.8, 4.7.5 and 4.8.0, Setup-specific URL-patterns that define exclusions to authentication are no longer active after the setup process has finished. - In Openfire 4.8.0, the embedded webserver will be updated to a version that no longer supports the non-standard URL encoding of UTF-16 characters. - In Openfire 4.8.0, the embedded webserver that serves the Openfire administrative console will bind to the loopback network interface by default.

Be aware that the new configuration properties can interfere with the functionality of certain Openfire plugins. This is especially true for plugins that bind a (web)endpoint to the embedded webserver that serves the Openfire administrative console, like current versions of the REST API plugin do. For these plugins to remain functional and/or reachable, it might be required to toggle the property adminConsole.access.allow-wildcards-in-excludes to true, and to avoid binding the embedded webserver to the loopback network interface only.

When your server uses older versions of the following plugins, make sure to upgrade them:

- Random Avatar plugin, update to version 1.1.0 or later. - Monitoring Service plugin, update to version 2.5.0 or later. - HTTP File Upload plugin, update to version 1.3.0 or later.

Mitigation If an Openfire upgrade isn’t available for your release, or isn’t quickly actionable, you can take any of the following steps to mitigate the risk for your Openfire environment.

Be aware: through Openfire plugins, the effectiveness of some mitigations listed below can be reduced, while other mitigations might affect the functionality of plugins. Particular care should be taken when using the Monitoring Service plugin, REST API plugin, User Service plugin and/or Random Avatar plugin.

Restrict network access Use network security measures (network ACLs and/or firewalls, VPNs) to ensure only trusted members of your community have access to the Openfire Admin Console. As a general rule, never expose the Openfire Admin Console to the general internet.

Examples: On a linux machine running ufw, deny ports 9090 and 9091 on non-loopback interfaces On a Windows machine, restrict the rules that open ports 9090 and 9091 to only allow traffic from the IPv4 and/or IPv6 loopback addresses On AWS cloud infrastructure, use EC2 Security Groups to restrict ports 9090 and 9091 to trusted IP addresses. If the trusted range is necessarily too broad, consider opening and closing the ports only as necessary If using Docker, instead of docker run ... -p 5222:5222 -p 9090:9090 -p 9091:9091 openfire prevent remote access to the Admin Console with docker run ... -p 5222:5222 -p 127.0.0.1:9090:9090 -p 127.0.0.1:9091:9091 openfire

Modify runtime configuration file To close the avenue of potential attack, a runtime configuration file of Openfire can be modified.

In Openfire's installation directory, find the file plugins/admin/webapp/WEB-INF/web.xml. After creating a backup of this file, edit the original file.

The content of this file is XML. Find a <filter> element, that contains the <filter-name>AuthCheck</filter-name> child element. Depending on your version of Openfire, it will look similar to this:

xml <filter> <filter-name>AuthCheck</filter-name> <filter-class>org.jivesoftware.admin.AuthCheckFilter</filter-class> <init-param> <param-name>excludes</param-name> <param-value> login.jsp,index.jsp?logout=true,setup/index.jsp,setup/setup-,.gif,.png,error-serverdown.jsp,loginToken.jsp </param-value> </init-param> </filter> The value inside of the param-value element is a comma-separated list of values. From this list, remove all (asterisk) characters.

Save the file, and restart Openfire for the change to take effect.

Note that no guarantees can be given that this runtime configuration change persists over time. Ensure to monitor the presence of the fix. It is recommended to upgrade to a safe version of Openfire as soon as possible.

A side-effect of this change is that the Openfire web-based setup wizard will not function properly (functionality can be restored by reverting the change). This wizard is typically used only when initially installing Openfire.

Bind admin console to loopback interface The Openfire admin console is a web-based application. By default, the corresponding webserver (that is embedded in Openfire) binds to all network interfaces of the host that it is running on.

The admin console can be configured to bind to a specific network interface. This will prevent it from being accessed through other network interfaces. By configuring the admin console to bind to the local loopback interface, it is accessible only to users on the server itself. This reduces the avenue of attack.

Note that several Openfire plugins expose part or all of their functionality through the admin console webserver. The REST API plugin, for example, serves its endpoints via this webserver. Availability of this functionality will be affected by binding the webserver to a specific network interface.

To bind the webserver of the Openfire admin console to a specific network interface, the 'openfire.xml' configuration file can be used.

In Openfire's installation directory, locate the file conf/openfire.xml. After creating a backup of this file, edit the original file.

The content of this file is XML. Find the <adminConsole> element that is a direct child element of the root <jive> element. Add a new element, named <interface> as a child element of <adminConsole>. The value of the <interface> element should be the name of the loopback interface or interface address. Setting value to 127.0.0.1 works on all tested environments (using values like lo on most Linux systems or lo0 on macOS will have the same effect).

The resulting fragment of the openfire.xml file will look similar to this:

xml <?xml version="1.0" encoding="UTF-8"?> <jive> <adminConsole> <interface>127.0.0.1</interface> <port>9090</port> <securePort>9091</securePort> </adminConsole>

...

Save the file, and restart Openfire for the change to take effect.

Use AuthFilterSanitizer plugin

The Ignite Realtime community has made available a new plugin, called the AuthFilterSanitizer plugin. The plugin can be installed from the Openfire admin console, or can be downloaded from the plugin's archive page on the IgniteRealtime.org community website.

This plugin periodically removes entries for Openfire's authentication filter that are susceptible to abuse, closing the avenue of potential attack.

Note that this plugin might interfere with functionality that depends on the abuse-susceptible entries in the authentication filter that might be provided by plugins.

Credit

This issue was originally reported by Siebene@ who has our gratitude for the responsible and detailed disclosure of the issue!

We are grateful for the resources made available by Surevine ltd. They were instrumental in addressing the issue listed in this advisory.

References - Ignite Realtime community site - Openfire releases download page - Openfire AuthFilter Sanitizer plugin releases download page - Openfire HTTP File Upload plugin releases download page - Openfire Monitoring Service plugin releases download page - Openfire Random Avatar plugin releases download page - OWASP: Path Traversal - Wikipedia: URL encoding, section 'Non-standard implementations' - Issue OF-2595 in Openfire's issue tracker - Jetty CVE-2021-34429

Common Vulnerabilities and Exposures assigned an identifier CVE-2014-0364 to the following vulnerability:

Name: CVE-2014-0364 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0364 Assigned: 20131205 Reference: http://community.igniterealtime.org/blogs/ignite/2014/04/17/asmack-400-rc1-has-been-released Reference: CERT-VN:VU#489228 Reference: http://www.kb.cert.org/vuls/id/489228

The ParseRoster component in the Ignite Realtime Smack XMPP API before 4.0.0-rc1 does not verify the from attribute of a roster-query IQ stanza, which allows remote attackers to spoof IQ responses via a crafted attribute.

It is not clear whether this flaw affects the version of smack in Fedora. Both of these look to be needed to complete the fix:

http://issues.igniterealtime.org/browse/SMACK-533 http://issues.igniterealtime.org/browse/SMACK-538

Common Vulnerabilities and Exposures assigned an identifier CVE-2014-0363 to the following vulnerability:

Name: CVE-2014-0363 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0363 Assigned: 20131205 Reference: http://community.igniterealtime.org/blogs/ignite/2014/04/17/asmack-400-rc1-has-been-released Reference: http://issues.igniterealtime.org/browse/SMACK-410 Reference: CERT-VN:VU#489228 Reference: http://www.kb.cert.org/vuls/id/489228

The ServerTrustManager component in the Ignite Realtime Smack XMPP API before 4.0.0-rc1 does not verify basicConstraints and nameConstraints in X.509 certificate chains from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate chain.

The man-in-the-middle attacker requires a certificate that is valid for any domain name.

Upstream patch: http://fisheye.igniterealtime.org/changelog/smackgit?cs=93030c218c62cf0a0a8ea48746db1452fa34033c

From code inspection, this issue affects the 3.2.2 version in Fedora (the CERT advisory mentions version 3.4.1 and possibly earlier versions).

Multiple cross-site scripting (XSS) vulnerabilities in Ignite Realtime Openfire 3.6.2 allow remote attackers to inject arbitrary web script or HTML via the (1) log parameter to (a) logviewer.jsp and (b) log.jsp; (2) search parameter to (c) group-summary.jsp; (3) username parameter to (d) user-properties.jsp; (4) logDir, (5) maxTotalSize, (6) maxFileSize, (7) maxDays, and (8) logTimeout parameters to (e) audit-policy.jsp; (9) propName parameter to (f) server-properties.jsp; and the (10) roomconfigroomname and (11) roomconfigroomdesc parameters to (g) muc-room-edit-form.jsp. NOTE: this can be leveraged for arbitrary code execution by using XSS to upload a malicious plugin.

ConnectionManagerImpl.java in Ignite Realtime Openfire 3.4.5 allows remote authenticated users to cause a denial of service (daemon outage) by triggering large outgoing queues without reading messages.

The admin console in Ignite Realtime Openfire 3.3.0 and earlier (formerly Wildfire) does not properly specify a filter mapping in web.xml, which allows remote attackers to gain privileges and execute arbitrary code by accessing functionality that is exposed through DWR, as demonstrated using the downloader.

Cross-site scripting (XSS) vulnerability in the login form (login.jsp) of the admin console in Openfire (formerly Wildfire) 2.6.0, and possibly other versions before 3.5.3, allows remote attackers to inject arbitrary web script or HTML via the url parameter.

Cross-site scripting (XSS) vulnerability in the login form (login.jsp) of the admin console in Openfire (formerly Wildfire) 2.3.0 Beta 2 allows remote attackers to inject arbitrary web script or HTML via Javascript events in the username parameter, a different vulnerability than CVE-2005-4876.

Cross-site scripting (XSS) vulnerability in the login form (login.jsp) of the admin console in Openfire (formerly Wildfire) 2.2.2, and possibly other versions before 2.3.0 Beta 2, allows remote attackers to inject arbitrary web script or HTML via the username parameter, a different vulnerability than CVE-2005-4877.